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37 C.F.R. § 41 .37(c)(i) Real Party in Interest 

The real party in interest in this Application is the United States of 
America. The present application is assigned of record to the United States of 
America, as represented by the Secretary of the Army. 

37 C.F.R. § 41 .37(c)(ii) Related Appeals and Interferences 

None. 
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37 C.F.R. 41 .37(c)(iii) Status of Claims 

The claims are 31 to 49. Claims 31 to 40 and 45 to 49 stand rejected 
under 35 U.S.C. § 102(b) as being anticipated by United States Patent 6,263,255 
to Tan and Vines. In addition, Claims 41 to 44 stand rejected under 35 U.S.C. § 
103(a) as being anticipated (sic) by United States Patent 6,263,255 to Tan and 
Vines in view of United States Patent 6,726,764 to Mutti and Voronknov. This 
Appeal is taken from the rejection of all claims. 

37 C.F.R. § 41 .37(c)(iv) Status of Amendments 

There are no unentered amendments. 

37 C.F.R. § 41 .37(c)(v) Summary of The Claimed Invention 
(a) Summary 

The present invention is directed to a model based controller system 
comprising: 

a development environment comprising at least one recipe for a process, 
each said process defined by a plurality of models, with each said model 
corresponding to at least one process step within said recipe; 
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an execution environment in operative communication with said 
development environment, and which execution environment comprises an 
execution platform capable of executing a recipe from said development 
environment; 

a coordination environment in operative communication with said 
execution environment and, through said execution environment, with said 
development environment, and which coordination environment coordinates 
information flow from said execution environment, and through said execution 
environment, said development environment and said model; 

a control level in operative communication with said coordination 
environment and, through said coordination environment, with said execution 
environment and said development environment, and in operative 
communication with at least one controller which is capable of controlling at least 
one component in the execution of at least one process step as defined by said 
model and communicated by said coordination environment; 

and wherein, said controller sends a control command corresponding to a 
process step defined by said model communicated to said controller from said 
model within said development environment through said execution environment 
and through said coordination environment, to said component, and said 
component sends a component information element to said controller, which 
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component information element is communicated through said coordination 
environment to said execution environment in which the performance of said 
process step may be varied in accordance with said component information 
element. 

(b) Background 

In current industrial, manufacturing, and data processing 
environments, process control is often necessary in order to ensure proper operation 
of a process. Process control may require the performance of a series of steps, such 
as in a particular order or at a particular time, in order to maintain a process within 
given tolerance levels, thereby ensuring process repeatability. Often, the result of a 
process is highly dependant on predefined tolerances subject to process control. 

To this end, process controllers are often implemented in order to 
maintain processes within given tolerance levels. In a typical embodiment, a system is 
designed around controlling of hardware or software that directly controls a process. 
For example, control may be constructed around the programming of a physical 
component to perform step A at set point X, step B at set point Y and step C at set 
point Z. In such an embodiment, an error in the process that causes the non- 
occurrence of, for example, process variable 1 not reaching set point X, may cause the 
non-occurrence of, for example, step A, until the process controller is reprogrammed 
to look for an alternative set point in order correct the problem. 
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Such programming for error control may typically be performed by a 
process engineer, which process engineer must be familiar with the particular 
programming language of the control unit at issue, and must further be aware of where 
the error problem has arisen within the code of that controller. The process engineer 
may then model a correction patch, and must then generate program code, in the 
correct language of the control unit at issue, for entry into the control unit by hard 
coding, in order to correct the error problem. In this scenario a model is a 
mathematical algorithm that results in the suggestion of a corrected path based on 
inputs of the current process state. Thus, a process engineer must generate a model 
for correcting the error, must turn that model into the proper coding language, and 
must enter that coding language directly into the controller. Such a methodology of 
error correction requires extensive training for process engineers, and requires a great 
deal of human interaction and training in order to maintain processes within given 
tolerances. 

Thus, the need exists for a controller environment in which a model 
may be developed, and universally coordinated with a controller, without a requirement 
for extensive training or interaction from a process engineer. Such a system may 
preferably provide for the development of a computerized model, wherein the 
computerized model, via a coordination interface, may intelligently select when control 
is necessary, and may interface with a controller operating in any controller language 
upon sensing that the model operation is necessary. 
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(c) The Invention 



It is to be understood that the figures and descriptions of the present 
invention have been simplified to illustrate elements that are relevant for a clear 
understanding of the present invention, while eliminating, for purposes of clarity, many 
other elements found in a typical control system and method. Those of ordinary skill in 
the art will recognize that other elements are desirable and/or required in order to 
implement the present invention. However, because such elements are well known in 
the art, and because they do not facilitate a better understanding of the present 
invention, a discussion of such elements is not provided herein. 

Figure 1 is a block diagram illustrating a model based controller 
("MBC") system 10 in accordance with the present invention. The MBC system (10) 
may provide a coordination environment 12 that coordinates information flow, such as 
data flow, between at least one model 13 and at least one controller 16, which 
controller 16 may control at least one additional component 18. The MBC (10) may 
include a plurality of environments, such as an execution environment 14 and a 
development environment 20, and thus may include an application integrated 
development environment ("IDE" or "AIDE") (21) within the development environment 
(20), and at least one execution platform (15) within the execution environment. 
Within, or associated with, the IDE 21 , the MBC 1 0 may additionally include a 
framework 22, a runtime platform 24, a recipe generation and/or edit platform 26, and 
at least one server 28, such as a coordination environment server. The at least one 



server 28, or server programs associated with the server, may be platform and/or 
operating system independent, such as OPC, DCOM, or XML. The development 
environment (20) and execution environment 14 may additionally include other 
facilities to control simulated or hardware components for, for example, real time 
control. 

The coordination environment 12 may be, for example, a server, or 
software thereon, such as an interface, that coordinates the data flow between the at 
least one model 13 and the at least one controller 16. The coordination environment 
12 receives and processes commands from the model 13 to control the controller 16, 
and receives and processes information received from the controller 16 for placement 
into the model 13, thereby allowing the model 13 to monitor and control a process via 
the coordination environment 12. 

Figure 1A is a graphical illustration of a coordination environment 12 in 
accordance with the MBC system 10 of Figure 1. The coordination environment 12 
may coordinate at least one of a plurality of models such as 1 3 with at least one of a 
plurality of available controllers such as 16, as set forth hereinabove, such as over a 
network 1 00, and such as by the at least one server 28. For example, the at least one 
model 13 may be one of a plurality of models within a recipe, and the at least one 
controller 16 may be one of, for example, a plurality of programmable logic controllers 
each having alarms and/or controls associated therewith, or one of a plurality of input- 
output (I/O) ports within, or associated with, a programmable logic controller, for 
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example. The at least model 1 3 may be remote from at least one of the coordination 
environment 12 and the control level 16, and each element of the MBC 10, namely at 
least the model 13, coordination environment 12, and the control level 16, may exist in 
hardware or computer programming, such as on the at least one server 28, with the at 
least one server 28 capable of remote communications, such as over a network, such 
as the internet. Thus, the ability of the MBC 10 to control a process, or to engage in 
logic, may be a function of the data rate capabilities of the network, servers, and the 
like, associated with the MBC 10. 

Returning now to Figure 1 , the development environment 20, such as 
the IDE 21 , may allow for the development or review of a pre-existent recipe or a 
recipe generated from, for example, the recipe generation platform 26, for execution 
on the execution platform. Thus, the development environment 20 may allow for 
attachment directly to a running controller 16, or over a network to a running controller 
16, for review and editing of the pre-existent recipe on that running controller 16, or 
may allow for creation of a new recipe to run the at least one controller 1 6. The 
development environment 20 preferably treats a controller 1 6 as an object for control 
by at least one model 13, thereby eliminating the need to hard code selected set 
points into the controller 1 6 itself. In this manner the development environment 20 can 
use the model 1 3 to vary the controller 16 as an object, and after the desired set 
points. The relation of the model 13 to the controller 1 6 as an object makes obvious to 
a user, such as a process engineer, the coordination between the controller 16 and the 
model 13, unlike the hard coding relationship of the prior art. 
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The IDE 21 may allow for extensions, via a component object model 
such as a (COM) or a XNL Services, for example, to enable the control of numerous 
different components via the same, or an associated, MBC 1 0. The development 
environment 20 may, for example, present a plurality of selectable components or 
preexistent models, as discussed further hereinbelow, which may, for example, be 
dragged and dropped into a developing recipe project. The development environment 
20 may include, for example, programming in Visual Basic, Visual C++ such as a 
(COM) or a XNL Services and/or Microsoft Windows 2000 Professional. 

The development environment 20 may additionally include, such as 
within or associated with the IDE 21 , a recipe edit platform 26 of the IDE 21 , which 
may allow the viewing and editing of at least one running recipe, or of at least one 
recipe project created within the IDE 21 . The recipe edit platform 26 may allow, for 
example, the entry of multiple recipe steps, the reordering of steps, pre and post step 
work, looping and branching control, timing controls, and the like. The recipe edit 
platform may allow for drag and drop, right click menus, pop up menus, or menus 
displayable by activation of, for example, functional keyboard keys, which menus may 
include help instructions to perform functions within a recipe, editing or monitoring of 
time for a loop within the recipe or for a step within the recipe, and/or tabbed views, 
such as a recipe tree, a recipe sheet, and/or a recipe code window, for example. Each 
step within the recipe may be accessible within a window for editing of each recipe 
step, as illustrated in the exemplary screen shots of Figure 2. 
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Returning now to Figure 1 , the development environment 20 may 
further include, for example, a component browser 32. The component browser 32 , 
as illustrated in the exemplary screen shots of Figure 3, may display the components 
that have been, or may be, selected for a current recipe project in development. The 
component browser 32 may allow for selection of components, or operational methods 
for components, for use in recipe steps, and/or for selection of components or 
component properties for display within certain windows. These display windows may 
include a watch window for watching an ongoing or active recipe, which watch window 
may illustrate, for example, true or false real time status of at least one selected recipe 
step condition, or a data collection window for watching active data accumulation, 
which data collection window may provide a capability to save data, such as a non- 
overwriteable date/time stamped save. The component browser 32 may provide a 
tree representation of components, for example, and may additionally provide the 
methods and/or properties of the components, including, for example, the component 
parameters, data types and/or property data types, of the displayed or selected 
components. 

The development environment 20, and/or the execution environment 
14 may share a simulator, wherein the simulator may include the operational methods 
of a plurality of hardware elements. A recipe may be developed using the available 
simulated hardware components, which simulated components, upon execution of the 
recipe, will provide feedback that simulates the actual hardware that provides the basis 
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for the simulated hardware. The behavior of the simulated components may be 
experimentally defined, such as by monitoring of actual hardware and saving 
performance data to simulator files. These simulator files may then be accessible to, 
or downloaded to, the MBC 10 as selectable components. 

Figure 3 is an exemplary screen shot illustrating component selection 
available within the component browser 32. Components may be selectable, for 
example, using point and click methodologies, treed methodologies, file menu 
methodologies, or may be imported via, for example, drag and drop and/or right click 
methodologies. The component selection module within the component browser 32 
may allow for selection of components recognized by, and/or registered with, the 
operating system or the MBC as MBC components, and may allow for component 
selection for recipe projects. In the treed format illustrated in Figure 4, component 
libraries, and components included therein, may be selectable from the tree. 
Component selection may be used during recipe creation, or when adding 
components to an existing recipe. 

The framework 22 may provide the functionality within the 
environments of the MBC 10, such as the development environment 20 and the 
execution environment 14. For example, the framework 22 may provide 
Open/Close/Save for recipe projects, or recipe files, within a recipe; the addition, or 
undo, of at least one component to a recipe; drag and drop, and/or cut and paste, from 
window to window within the MBC, and/or to or from exterior applications via, for 
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example, importation to the MBC 10; execution command for running at least one 
recipe; debug of components or at least one recipe; Open/Close for windows such as 
recipe watch, data collection, recipe viewer, etc.; and support, such as at least one 
help menu. In order to provide these functions, the framework 22 may include system 
menus, system help, IDE window coordination, and/or toolbars, as will be apparent to 
those skilled in the art. Further, as used herein, toolbar, single arrow, double arrow, 
file menu, drop down menu, hyperlink, tab menu, or treed menu, for example, may be 
used interchangeably unless then/vise noted, and are provided by the framework 22. 
In an exemplary embodiment of a window provided in the framework 22, Figure 4 is a 
screen shot illustrating primary interfaces for a recipe development session, such as 
within the development environment 20. 

Each recipe developed and/or executed in the present invention may 
implement at least one model 13, as discussed hereinabove. Each recipe that 
includes the at least one model 13 may monitor at least one method, process, or data 
flow, for example, wherein each model 13 within the recipe may control and/or monitor 
at least one aspect of the method, process, or data flow, for example. For example, a 
recipe may be generated to control the growth of a given crystal. Each model within 
the recipe may then monitor and/or control a particular aspect of the growth of the 
crystal. 

In this exemplary embodiment, the crystal may grow over time, 
preferably within a given tolerance for growth rate, which tolerance is monitored and 
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controlled with improved consistency through the use of the present invention. For 
example, as illustrated in Figure 5, a recipe A including twelve models that control the 
growth of the crystals, which recipe A may, at predetermined times, and/or at 
predetermined intervals, call models B and C, wherein models B and C may monitor 
particular aspects of the given crystal growth within the process controlled by master 
recipe A. Thus, for example, if model A monitors that the crystal growth is occurring 
too quickly, recipe A may run model F, wherein model F may provide process 
temperature change suggestions in order to bring crystal growth back within tolerance 
levels. However, for example, if recipe A monitors that crystal growth is occurring too 
slowly, recipe A may run model G, wherein model G may suggest the input of a 
particular gas in order to stimulate growth of the crystal, and wherein model G may call 
model F to suggest temperature changes to stimulate crystal growth. Additionally, as 
will be apparent to those skilled in the art, recipe A may then call model D, model E, 
and model J, each individually, in sequence, or all simultaneously, such through the 
use of object oriented programming. Thereby, the recipe may provide real time 
process control over the growth of the crystal, and tolerance levels may be maintained 
more consistent throughout repetitions of the process through the use of the same 
coordination environment. 

Thus, the recipe may operate heuristically in order to maintain the 
process at predetermined tolerances. For example, although a given model may 
include that process occurrence X occurs at motor speed 30 RPM, the model may be 
alerted by the control that X has occurred at motor speed 22 RPM, and may vary the 
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process accordingly pursuant to an understanding that occurrence X is the goal, rather 
than the assertion that condition motor speed 30 RPM would accomplish X. Further, 
those skilled in the art will appreciate that, in accordance with this methodology, steps 
within a first recipe or first model may be responsive to, or dependent on, steps within 
a second recipe or second model, wherein the first recipe or model is in 
communicative connection with the second recipe or model via the MBC coordination 
environment. 

Each model within the recipe may pass information through the 
coordination environment to an I/O port, or to a programmable logic controller. 
Further, as set forth hereinabove, a plurality of models may be coordinated with a 
plurality of controllers via the coordination environment. Each I/O port, or each 
controller, may then be responsible for controlling a particular aspect of a process, 
such as the crystal growth environment discussed hereinabove. In prior art 
embodiments, different models or types of I/O port, or different types or models of 
controllers, such as programmable logic controllers, may have been substantially 
unable to directly interface with one another in order to provide uniform and overall 
process control across the different models or types. This inability to interface often 
occurs in the prior art due to the use of different brands, or types, of controllers, which 
may, for example, employ different interface capabilities or computer programming 
language capabilities, and this inability to interface is remedied, in part, through the 
use of the present invention. 



15 



Thus, the coordination environment of the present invention allows for 
multiple controllers, each of which may operate in accordance with a different 
operating environment, which different operating environments may be remote from 
the coordination environment 12 and/or the model environment, to operate in unison in 
accordance with at least one model 13 or recipe communicating through the 
coordination environment 12. Additionally, the present invention allows for the 
replacement of equipment, or controllers, within the controller environment 
communicating through the coordination environment 12. For example, two models 
programmed with the tolerances, and technical aspects, of each of the old and the 
new equipment, respectively, may be adjusted accordingly for the incorporation of the 
new equipment without substantial variation to the recipe. This switching between 
models within the recipe may be engaged, for example, by the process engineer, upon 
installation of new equipment, without any substantial reprogramming by the process 
engineer. Thus, the process engineer need not know the nuances of the model or 
models run within the recipe, but rather need only know the equipment or controllers 
availabe in the controller environment communicating through the coordination 
environment, and need only instruct the coordination environment 12 as to the 
presence of particular equipment or controllers in communication with the coordination 
environment 12. 

Returning now to Figure 1, the execution environment 14 may include, 
for example, the ability to monitor the running of a recipe in run-time, and/or to 
interactively monitor component property values during execution, and/or the ability to 
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monitor and/or collect data during run-time. For example, Figure 6 is a screen shot 
within the execution environment 14 illustrating a viewer for viewing the run-time of a 
recipe. In the exemplary embodiment illustrated, material viewable from within the 
recipe run-time viewer may be included, and/or presented, within a COM library, such 
as a library denoted "recipe interface". The run-time viewer may be a stand alone 
application, for example, or may additionally be integrated with, or within, the IDE 21 . 

In this exemplary embodiment of an execution environment, the 
viewing of run-time component property values may be enabled through the use of a 
watch window, such as that illustrated in the screen shot of Figure 7. The watch 
window may be, for example, a dockable or floating window that enables a user to 
monitor component property values, such as during run-time or debugging. The watch 
window may additionally include a plurality of tabbed views, wherein varied watch 
configurations may be made available by clicking on selected ones of the tabs. As 
used herein, one skilled in the art will appreciate that tabs may include, for example, 
selectable drop-down menus, point and click menus, hyperlink menus, and the like. 

Additionally, in this exemplary embodiment, a data collection window 
may be included in the execution environment, such as that illustrated in the screen 
shot of Figure 8. The data collection window may be a dockable or floating window 
that enables the monitoring and/or storing of component property values during recipe 
execution. The data collection window may include, for example, tabbed views similar 
to those discussed hereinabove with respect to the watch window. The data collection 
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window may, for example, collect data and allow for display of that data to a user at a 
predetermined minimum rate commensurate with the change rate of the data of 
interest, such as, for example, at least once ever two seconds. Data collection 
capabilities accessible via a data collection window during run-time may include, for 
example, file compression, storage to at least one file types, such as, for example, to a 
spreadsheet or .CSV file, and the data collection window may include a configurable 
storage directory. 

Further, preferably within the watch window, the data collection 
window, or a storable file, applicable programming code for the recipe run may be 
made available and/or recordable, such as for review of the recipe run by an MBC 
user. For example, a run file may be created for the running of a particular recipe, 
which run file may be saved, for example, to the desktop. This methodology of file 
saving may allow, in an exemplary process, tracking of the time of occurrences in the 
recipe run at the shortest time frame provided by the computer operating system on 
which the run code is generated. 

Each of the development environment and the execution environment 
preferably allows for the configuration and/or monitoring of the components, and/or 
libraries of components, employed in the recipes of the present invention. Figure 9 is 
a block diagram illustrating an MBC component. An MBC component is any software 
or hardware item that provides, or allows connection to, an open interface, such as 
COM or XML Services, that self-registers, or that can be registered, with, for example, 
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a Windows operating system environment, such that the IDE can locate the 
component during recipe development, and such that the execution environment can 
locate the component during execution. Further, the components of the present 
invention preferably implement at least one component interface. Figure 1 0 is a chart 
illustrating a list of exemplary components, which may be available, for example, via 
an MBC component library. 

Open Interface, such as COM or XML Service, as used herein, allows 
applications and systems to be built from components supplied by different hardware 
and/or software vendors. COM or XML Services may be an architecture employed to 
form foundations for higher level software services. Higher level software services 
may span varied aspects of component software, such as compound documentation, 
custom control, inner application scripting, data transfer, and the like. COM or XML 
Services is an architecture that defines a binary standard for component 
interoperability, is programming language independent, may be provided on multiple 
platforms, provides a robust environment for evolution of component based application 
and systems, and is extensible, as will be apparent to those skilled in the art. In 
addition, COM and XML Services may allow for communication between components, 
such as across process or network boundaries, shared memory management as 
between a plurality of components, error and status reporting for components, and the 
dynamic loading of components. 
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Returning now to Figure 9, an MBC component is a building block 
within the MBC system. An MBC component is present within the IDE in order to allow 
for the creation of recipes, for example, and an MBC component is executed within the 
recipe upon execution in the execution environment, as discussed hereinabove. An 
MBC component may exist, for example, as a COM object within a COM library, or as 
a stand alone XML Service, as set forth hereinabove. A component library may be, for 
example, a collection of classes that have implemented at least one open interface. It 
will be apparent to those skilled in the art that an MBC component may be 
implemented by an interface, such as by a secondary class interface separate from a 
first component interface, which secondary interface may allow the IDE 21 , and/or a 
component configuration utility within, or in association with the IDE 21 , to properly 
address MBC components in a uniform fashion. For example, Figure 1 1 is a block 
diagram illustrating the addressing relationship between an MBC component and other 
MBC system elements. 

In accordance with Figure 1 1, an MBC component may register, or be 
registered, with the operating system registry, such as a Windows registry, such as 
through the use of a registration wizard, which registration wizard may respond either 
automatically within the MBC, or to a user request for component registration. For 
example, upon implementation of the IDE 21 or execution environment 14 or 
configurations, a search may be performed for components in the operating system 
registry, and that search may allow for the building of at least one MBC component 
library of registered components. The component list may then be made available to 



20 



the recipe developer within both the IDE 21 and the execution configurations. Upon 
selection of a set of component libraries, the MBC components may be interrogated, 
via, for example, the COM or XML Service interfaces respectively, to assess the 
method, properties, and configuration of each MBC component. Within the IDE 21 , 
the MBC components may be presented as a selectable list of available libraries, such 
as for different tasks, recipes, or model types, wherein each library may contain the 
methods, properties, and configurations then used to create recipes. 

In addition, it will be apparent to those skilled in the art that new 
communication elements or types, unknown by the registration wizard, may be 
programmed into the registration wizard. For example, in an embodiment wherein a 
particular device communicates serially, such as directly with a PC, the registration 
wizard may be programmed to read a computer serial port in order to receive data 
from, and thereby allow for registration of, that serial device. This addition of new 
device types may include a hard coding of new device types, a file download of new 
device types, or a creation of new objects within an object-oriented environment for 
new device types, for example. It will be further apparent that, in an embodiment 
wherein, for example, a programmable logic controller (PLC) is capable of direct 
communication with the new device, such as the new serial device, and wherein the 
PLC is already registered as a component, the new device need not be registered as a 
component, but rather may be controlled by the MBC by exertion of control over the 
PLC to which the new device is communicatively connected. 
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In an exemplary embodiment of registration, selectable components 
may include hardware components, such as programmable logic controllers (PLCs), in 
certain embodiments of the present invention. These components that are controllable 
and registerable with the MBC 10 may be automatically added to a list of eligible 
components upon communicative connection to the MBC, or upon a search for eligible 
components as described hereinabove, such as by an automated sensing of the 
communicative connection, a reading of the tags from a PLC upon the automated 
sensing, wherein the tags include information pertaining to communication protocols 
for the PLC. Upon the reading of tags and initiation of a COM object, the PLC may be 
registered and made available for recipe projects. The ability to automatically 
communicate with numerous controllers of different makes, models, or communication 
types provides interoperability across controller platforms in the present invention. 
Further, it will be apparent to one skilled in the art that this methodology may be 
extended, for example, to different kinds of hardware, such as sensors, valves, 
actuators, motors, and the like, inter-communicating with each other and one or 
multiple controllers, via the use of the component registration of the present invention. 

An MBC component may be formed and formatted using, for example, 
visual basic. Figure 12 is a flow diagram illustrating the development of an MBC 
component, wherein the steps of the development may include creation of an 
abstraction for the component, the creation of a COM or XML Service interface for the 
component, the implementation of the secondary interface for the component, the 
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registration of the component with the operating system, and the integration and 
testing of the component. 

The first step of the development of the MBC component may be the 
development of an abstraction component. Upon completion of the development of 
the abstraction, a COM or XML Service interface may be created for the component. 
A COM or XML Service interface may be created in, for example, visual basic as, for 
example, an ACTIVEX DLL or EXE file. Project settings may determine the name of 
the component library, and the classes of the library may determine the components 
allowable therein. Thus, using visual basic, in order to create an MBC component and 
library, an ACTIVEX DLL or EXE file may be created for the project, and one or more 
classes may be added to the project. The name of each class may determine the 
name of the component, as will be apparent to those skilled in the art. Subsequently, 
methods and properties may be added to each class in order to implement the 
abstraction of the component developed hereinabove. References may be added for 
the MBC library and type libraries, and a DLL or EXE may be built. 

The implementation of the secondary interface discussed hereinabove 
allows the MBC system applications, including the IDE 21 and the component 
configuration utility, to treat MBC components in a uniform way, as set forth 
hereinabove. The secondary interface methodologies and properties may not be 
visible from within recipes, such as during recipe development. 
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A UML diagram for an exemplary secondary interface is illustrated in 
Figure 1 3. With respect to Figure 1 3, a variable component name is a fully qualified 
name for the component, and includes the library of the component. The "I/O point 
list" may be a collection of I/O point objects, for example. "State" may be an integer 
value that represents the internal state of the MBC component. "State name" may be 
the string representation of the state of a given variable. "Save configuration" may be 
used to save a component's configuration, which may include the name of the 
component and the I/O point list of the component. "Load config" may be used to load 
a component's configuration. "Validate command" may be used to check the set point 
for an I/O point value against the I/O point valid range of values. "Initialize" may be 
used to initialize the component. "Reset" may be used to reset the component. An 
exemplary hardware point object list for an MBC component is illustrated in Figure 14. 

Additionally, the MBC component and component library may be 
registered with the operating system, as set forth hereinabove. This may be done, as 
will be apparent to those skilled in the art, via a variety of methods, including the 
creation of a key for registration. The registration key for, for example, the IDE tool, 
may include the values for persisting the state of the IDE tool, such as user preference 
values, window size and location values, and file list values. Each component may 
create its own key value for registration. Upon a registration, or an attempted 
registration, the component and library may be tested. 
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The component library may be tested, for example, by testing that the 
component is a valid COM or XML Service object, has implemented the secondary 
interface, has a correctly implemented an abstraction, and operates correctly with the 
IDE. The component library may be tested using the MBC configuration utility. 
Further, in order to test the components and component library, the library registration 
may be checked. Figure 1 5 is a screen shot illustrating the testing of library 
registration. Wherein a component library is correctly registered with the MBC system, 
the component library or libraries may be displayed within the MBC component 
configuration. 

In order to test that a component is a valid COM or XML Service 
object, a library may be selected that contains a component in question from the 
library list, as illustrated in the screen shot of Figure 16. Valid COM or XML Service 
objects may be displayed within the library, such as within the tree view of the library, 
as illustrated. 

In order to test for the secondary component implementation, each 
object in a component library may be associated with a flag, wherein the flag is set to 
provide recognition that the secondary interface has, or has not, been implemented. 
In an embodiment wherein the secondary interface has not been implemented for the 
selected component or component library, a warning message may appear. 
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In order to test the component abstraction implementation, a subjective 
evaluation may be made, wherein the subjective evaluation may, for example, test the 
component within the IDE against, for example, a simulation, and may test the 
component again in, for example, the run-time environment. In order to test the 
component abstraction implementation in the IDE, the IDE may be started and a 
component library may be selected for checking of the component library methods and 
properties within IDE, as illustrated in the screen shot of Figure 17. The abstracted 
components may then be tested in a recipe, such as that illustrated in Figure 18. In 
order to assess the correct function of a component from within the execution 
environment, for example, a property of the component may be added to, for example, 
the watch window, as discussed hereinabove. If a component has been properly and 
successfully created, the property may display in the watch window as illustrated in 
Figure 1 9. If the component was improperly created or constructed, an error message 
may appear. 

In operation, the MBC system may include a developed recipe. The 
recipe may be developed by entering the IDE, and opening an existing recipe project, 
or by creating a new one. The recipe may be developed by the addition of 
components, the creation of recipe steps and/or recipe models, the addition of 
components to the recipe or model steps, and the collection of set-up data. The recipe 
may then be debugged, such as through the use of watch windows, the display of 
recipe break points, a review of captured data from recipe execution, or by 
troubleshooting the logic of the recipe. Following debug, a recipe may be saved, 
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and/or deployed. The components for the recipe used may be developed using, for 
example, Visual Basic, Visual C++, Java, C# or Delphi, and the components 
developed are preferably registered with the operating system or MBC environment 
prior to use within a recipe. 

Upon validation of the recipe, a process may be controlled, such as via 
a combination of a controller, and a model. The recipe may thus include the 
coordination between the controller and the model. The process may be dynamically 
controlled, or predictively controlled. With dynamic control, the recipe may set model 
input properties based upon process input data. The recipe may further call a model 
in order to calculate outputs based upon the model input properties, and may then 
update the model in accordance with output properties. The model outputs may then 
be used by the recipe to control the process. For predictive control, the recipe may 
initialize start-up parameters, and may call a model to produce predictive data for the 
running of the process. The recipe may then capture the model predictive data in, for 
example, a memory, such as a table. The recipe may then make calculations using 
the model predictive data, and may control the process in accordance with these 
calculations. 

Thus, as set forth hereinabove, in order for the recipe to exercise 
predictive or dynamic control of a process, the recipe may be executed by the 
execution environment, such as by a recipe execution engine. Recipe execution may 
include the execution of the series or plurality of recipe steps, such as in the form of 
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models as discussed hereinabove, which recipe steps may include, for example, 
component methods, pre and/or post processing logic, branching or got logic, move on 
conditions, loop indicators, loop times, and/or step times. The component methods 
may include at least one method call in accordance with a hardware component set 
point, in order to allow for control of that hardware component within predetermined 
tolerance levels. Preprocessing logic may be executed at the beginning of a recipe 
step. Post-processing logic may be executed at the completion of a recipe step. 
Preprocess and Post processing logic may redirect the recipe execution to a goto, or 
to branch to another recipe step. For example, preprocessing logic may compare a 
temperature reading and determine that a emergency flush of a container is 
appropriate. The preprocessing algorithm might, in this exemplary embodiment, call a 
Goto function with the name of the recipe step that executes the emergency flush. 
Preprocessing or postprocessing logic may also branch to a series of steps and return 
to the original step upon reaching a return recipe step, for example. Move on 
conditions may, for example, include Boolean expressions that are evaluated in order 
to determine whether the recipe can move to a subsequent recipe step. For example, 
an expression may be developed that will allow for the running of a particular model 
until a predetermined condition is met, and, upon the meeting of that condition, 
another recipe step, or a different model, may be allowed to run. In an exemplary 
embodiment employing control of a motor, the recipe may not be allowed to move to a 
next step until the controller tells the model that the motor has reached a speed preset 
within the move on step, such as a certain number of RPM. Loop indicator may 
include a Boolean expression that determines whether the recipe can execute the 
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component methods in a loop. Loop time may determine the execution frequency of a 
recipe step loop, and step time may determine the maximum duration of a recipe step. 

Also, as set forth hereinabove, in order for a recipe to be executed in 
the execution environment, the recipe may be developed in the development 
environment, such as in the IDE. Figure 20 is a screen shot illustrating the opening of 
an IDE application. The IDE application may include a plurality, such as six, IDE 
components. The IDE components may include, for example, a recipe editor that 
creates, debugs, and/or prepares recipes to run, an MBC component browser to 
facilitate recipe creation, a watch window that allows for the viewing of recipe progress 
during debug, and a framework for inter-process communication and recipe 
development. An exemplary IDE layout is illustrated in the screen shot of Figure 21 . 
Figure 21 illustrates a split layout, thereby providing increased user convenience. The 
exemplary split layout illustrated employs a tree layout of recipe components on the 
left-hand side of the screen, wherein the components displayed are components of the 
recipe step selected on the right hand side of the screen. The right hand side of the 
screen provides a tree layout of the recipe, including each of the plurality of models, or 
recipe steps. Information is given as to each of the plurality of recipe steps, such as 
move on function to allow for selection of a proper move on point during execution, 
and a loop, loop time, and step time function for the selected recipe step. The IDE 
layout illustrated in Figure 21 includes at least one watch window, wherein the watch 
window provides additional information regarding the recipe displayed. 
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In this exemplary operational embodiment, a new recipe may be 
created, such as by selection of a new recipe project from a selectable menu within 
the IDE. The user may be allowed to interactively select components for placement 
into the new recipe project. The selection of components may be allowable by a 
screen shot similar to that of Figure 22. Available components, such as those 
illustrated in Figure 22, may be viewed by expanding component categories, such as 
through the use of a treed menu. Components may then be selected or removed, 
such as through the use of single arrow buttons, double click, or the like. All 
components may be selected, or removed, simultaneously, or by category, for 
example, such as through the use of a selectable icon, or a double arrow button, for 
example. 

Upon selection of components, selected components may be explored 
within the IDE, such as through the use of a component explorer window as illustrated 
in Figure 23. As illustrated, the component explorer allows for the viewing of 
properties and methods of each component selected for a recipe project, and these 
properties and methods may be expandable, such as through the use of a treed menu. 
Components may additionally be added, or information as to components may be 
viewed, through selection of components within the component explorer window, for 
example. 

From within, or without, the component explorer, and/or the component 
selector and browser, a recipe may be edited. A recipe may be edited, for example, 
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through the use of a recipe editor, such as that illustrated in the exemplary screen shot 
of Figure 24. A step may be selected within the recipe editor, to which step a 
component is to be added. Upon selection of a given step, the components then 
involved in that step may be displayed, such as through the use of a treed menu. 
Further, selected aspects of that step and/or those components, may be displayed. 
Further, upon selection of a step, a step detail window may be available, as, for 
example, a pop-up window, or a selectable display window from, for example, a file 
menu or a hyperlink. Upon selection of a step detail window, such as that illustrated in 
exemplary screen shot of Figure 25, numerous aspects of the step may be illustrated. 
These aspects may include, for example, components included in the step, component 
commands included in the step, the number of the step, pre and post processing for 
the step, loop control for the step, and the ability to move, within the step detail 
window, between steps. It may also be allowable to enable and/or disable recipe 
steps, such as from within the recipe step detail. Further, multiple recipe steps may be 
block selected by methodologies apparent to those skilled in the art. 



(d) The Claims 



There are three independent claims. Claim 31 defines the model based 
controller, and support for this claim, while found inter alia, is found particularly at 
paragraphs 10 through 18 of the Specification, with each paragraph describing another 
element of the claimed system, and in Figs. 1 and 1 A. Claim 47 is a method claim 
which recites the elements of the system of Claim 31 and then describes how the 
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method is carried out by interaction of those elements. Claim 48 is directed to a 
machine-readable program which will install the elements of the system and carry out 
the method of interaction of those elements. 



37 C.F.R. § 41 .37(c)(vi) Grounds of Rejection to be Reviewed on Appeal 

Claims 31 to 40 and 45 to 49 stand rejected under 35 U.S.C. § 102(b) as 
being anticipated by United States Patent 6,263,255 to Tan and Vines. It is the 
Examiner's view that the reference shows each element of the claim, with the 
Examiner characterizing the language of the reference as somehow equivalent to 
the claims under examination. 

In addition, Claims 41 to 44 stand rejected under 35 U.S.C. § 103(a) as 
being anticipated (sic) by United States Patent 6,263,255 to Tan and Vines in 
view of United States Patent 6,726,764 to Mutti and Voronknov. With respect to 
each of these rejected claims, the Examiner acknowledges that the Tan and 
Vines reference does not expressly show some elements, such as the use of a 
programmable logic controller in Claim 41 , and relies on the disclosure of the 
Mutti and Voronknov reference for such missing element. 

37 C.F.R. § 41 .37(c)(vii) Argument 

The Examiner's rejections are respectfully traversed in their entirety. 
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The present invention is a model-based control system for an industrial 
process, not merely a step in an industrial process. That each step in an 
industrial process is often viewed as a process itself may be confusing. But the 
process of each process step is often managed by a controller for the equipment 
employed in that process step. The present invention is a control program 
intended to work with many such controllers sequentially, managing the entire 
process, and through the individual controllers, manage each individual process 
step within the process, according to a set of models for the overall industrial 
process. Further, the model-based controller of the present invention is not 
merely intended to direct the machines in which each industrial process step is 
carried out, but it is also intended to direct the movement of material from one 
process step to another. Nothing in the prior art even suggests such a possibility. 

United States Patent 6,263,255 to Tan and Vines is entitled Advanced 
Process Control For Semiconductor Manufacturing. The reference shows a 
framework designed to integrate commercially-available tools for the preparation 
of semiconductors. It is intended to enable vendors to create framework- 
compatible products with an open architecture. It is not a controller for an 
industrial process. 

United States Patent 6,726,764 to Mutti and Voronknov is entitled Method 
For Controlling Growth Of A Silicon Crystal To Minimize Growth Rate And 
Diameter Deviations. The reference discloses a control method for use with a 



33 



crystal puller for growing a monocrystalline semiconductor crystal from a melt. It 
is a controller for a process step, not a controller for an industrial process. 

There are many additional references which have been cited to the 
applicants in this and companion cases which are not yet before the Board. Each 
of these references deal with the control of a single process step, e.g., 
crystallization, rather than the overall control of an industrial process, such as a 
process where crystallization is but one process step. The present invention is 
broader in scope than any of these cited references, and attempts, successfully it 
should be noted, to coordinate the individual process steps through control of the 
individual, differently programmed, controllers. 

The primary reference, itself, demonstrates the need for such control, in 
proposing an open architecture for process control which would permit 
framework-compatible machinery. The inability of the marketplace to overcome 
the dedication of manufacturers to proprietary control software has thus far 
resisted the call to an open architecture. The present invention has pursued 
another route: a model-based controller which can speak to the proprietary- 
language controller of each process component. 

It would serve no purpose to argue each element that the Examiner has 
attempted to find in the primary reference. The rejection is an exercise in the 
semantics of the language employed, not the reality of the process controlled. 
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The primary reference remains a proposal for the control of one component in an 
industrial process and cannot rise to the level of control of an overall process. 
Certainly, a reference which does not propose to do what the present invention 
does cannot be said to anticipate the present invention. 

That certain hierarchical structures of the control system of the present 
invention are modeled within the controller of an individual process step is not 
surprising, for it is with such a structure that a process is controlled. However, in 
the present claims, the individual controller for a given process element is 
provided with a control command from an external hierarchical structure, which is 
then carried out by the controlled component. And the component sends a 
control information element which is communicated back through the individual 
component controller to the external hierarchical structure of the model-based 
control system of the present invention, permitting that process step to be varied. 

Likewise, the secondary reference, which also shows control of an 
individual process step, in this case crystallization, cannot add what is not shown 
in the primary reference, which is overarching external control of an industrial 
process. 

It is submitted that the system of the present invention and the systems of 
the cited references... all of the cited references... are on an altogether different 
scale. United States Patent 6,263,255 to Tan and Vines is not a control for an 
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industrial process but, in the sense of the present invention, a control of a single 
process step within an industrial process. The reference shows process control 
for the manufacture of semiconductors, not the control of an industrial process 
for the step-wise production of semiconductors from raw material handling to 
finished product. 

37 C.F.R. § 41 .37(c)( viii) Claims Appendix 

What is claimed is: 

1 to 30(cancelled). 

31 (rejected). A model based controller comprising: 

a development environment comprising at least one recipe for a process, 
each said process defined by a plurality of models, with each said model 
corresponding to at least one process step within said recipe; 

an execution environment in operative communication with said 
development environment, and which execution environment comprises an 
execution platform capable of executing a recipe from said development 
environment; 
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a coordination environment in operative communication with said 
execution environment and, through said execution environment, with said 
development environment, and which coordination environment coordinates 
information flow from said execution environment, and through said execution 
environment, said development environment and said model; 

a control level in operative communication with said coordination 
environment and, through said coordination environment, with said execution 
environment and said development environment, and in operative 
communication with at least one controller which is capable of controlling at least 
one component in the execution of at least one process step as defined by said 
model and communicated by said coordination environment; 

and wherein, said controller sends a control command corresponding to a 
process step defined by said model communicated to said controller from said 
model within said development environment through said execution environment 
and through said coordination environment, to said component, and said 
component sends a component information element to said controller, which 
component information element is communicated through said coordination 
environment to said execution environment in which the performance of said 
process step may be varied in accordance with said component information 
element. 
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32 (rejected). The model based controller of Claim 31 , wherein the coordination 
of said model with said controller comprises a data flow between said model and 
said controller. 

33(rejected). The model based controller of Claim 31 , wherein said controller is 
adapted to control a plurality of said at least one components. 

34(rejected). The model based controller of Claim 31 , wherein said development 
environment further comprises a recipe generator communicatively coupled to 
said plurality of models, and comprising means to add or amend recipes. 

35(rejected). The model based controller of Claim 31 , further comprising at least 
one server being communicatively coupled to said coordination environment. 

36(rejected). The model based controller of Claim 31 , further comprising at least 
one server being communicatively coupled to said development environment and 
to said plurality of models. 

37(rejected). The model based controller of Claim 31 , wherein said coordination 
environment comprises a server. 
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38 (rejected). The model based controller of Claim 31 , wherein said execution 
environment further comprises computing resources for real-time control of an 
execution mode. 

39(rejected). The model based controller of Claim 38, wherein said execution 
environment further comprises means to display the execution of said process. 

40(rejected). The model based controller of Claim 31 , wherein said at least one 
component comprises an operative component selected from the group 
consisting of a valve, a sensor, and a motor. 

41 (rejected). The model based controller of Claim 31 , wherein said at least one 
controller comprises a programmable logic controller. 

42(rejected). The model based controller of Claim 41 , wherein said coordination 
environment further comprises code for enabling communication. 

43(rejected). The model based controller of Claim 42, wherein said coordination 
environment further comprises code for modifying at least one recipe associated 
with said controller. 

44(rejected). The model based controller of Claim 43, wherein said code is 
responsive to at least one of said models. 
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45 (rejected). The model based controller of Claim 31 , wherein said execution 
environment further comprises at least one interface adapted to present 
information indicative of one of said models and said at least one component to a 
user. 

46(rejected). The model based controller of Claim 45, further comprising code for 
enabling said user to employ said interface to modify said model. 

47(rejected). A method of controlling a process, using a model based controller 
comprising: 

a development environment comprising at least one recipe for a process, 
each said process defined by a plurality of models, with each said model 
corresponding to at least one process step within said recipe; 

an execution environment in operative communication with said 
development environment, and which execution environment comprises an 
execution platform capable of executing a recipe from said development 
environment; 

a coordination environment in operative communication with said 
execution environment and, through said execution environment, with said 
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development environment, and which coordination environment coordinates 
information flow from said execution environment, and through said execution 
environment, said development environment and said model; 

a control level in operative communication with said coordination 
environment and, through said coordination environment, with said execution 
environment and said development environment, and in operative 
communication with at least one controller which is capable of controlling at least 
one component in the execution of at least one process step as defined by said 
model and communicated by said coordination environment; 

and wherein, said controller sends a control command corresponding to a 
process step defined by said model communicated to said controller from said 
model within said development environment through said execution environment 
and through said coordination environment, to said component, and said 
component sends a component information element to said controller, which 
component information element is communicated through said coordination 
environment to said execution environment in which the performance of said 
process step may be varied in accordance with said component information 
element; 

which method comprises the steps of: 
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selecting a recipe associated with a process having at least one process 

step; 

generating a model associated with each process step within said 
process; 

issuing at least one control command associated with each said model, 
which control command is communicated by said at least one controller to said at 
least one component; 

sending, by said at least one component, responsively to said at least one 
control command, of at least one component information element to said at least 
one controller; and 

communicatively coordinating each said model with the at least one 
controller, wherein said at least one control command is generated in accordance 
with the at least one process step, and wherein the at least one process step is 
varied in accordance with said at least one component information element. 

48(rejected). A computer-readable medium, carrying thereon at least one 
sequence of instructions for controlling a physical process, wherein the execution 
of said at least one sequence of instructions by at least one processor in 
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communication with at least one controller and at least one component creates a 
model based controller comprising: 

a development environment comprising at least one recipe for a process, 
each said process defined by a plurality of models, with each said model 
corresponding to at least one process step within said recipe; 

an execution environment in operative communication with said 
development environment, and which execution environment comprises an 
execution platform capable of executing a recipe from said development 
environment; 

a coordination environment in operative communication with said 
execution environment and, through said execution environment, with said 
development environment, and which coordination environment coordinates 
information flow from said execution environment, and through said execution 
environment, said development environment and said model; 

a control level in operative communication with said coordination 
environment and, through said coordination environment, with said execution 
environment and said development environment, and in operative 
communication with at least one controller which is capable of controlling at least 
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one component in the execution of at least one process step as defined by said 
model and communicated by said coordination environment; 

and wherein, said controller sends a control command corresponding to a 
process step defined by said model communicated to said controller from said 
model within said development environment through said execution environment 
and through said coordination environment, to said component, and said 
component sends a component information element to said controller, which 
component information element is communicated through said coordination 
environment to said execution environment in which the performance of said 
process step may be varied in accordance with said component information 
element; 

and permits the at least one processor to perform the steps of: 

selecting a recipe associated with a process having at least one process 

step; 

generating a model associated with each process step within said 
process; 
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issuing at least one control command associated with each said model, 
which control command is communicated by said at least one controller to said at 
least one component; 

sending, by said at least one component, responsively to said at least one 
control command, of at least one component information element to said at least 
one controller; and 

communicatively coordinating each said model with the at least one 
controller, wherein said at least one control command is generated in accordance 
with the at least one process step, and wherein the at least one process step is 
varied in accordance with said at least one component information element. 

49(rejected). The model based controller of Claim 38, wherein said execution 
environment further comprises means to monitor and control said process. 

37 C.F.R. § 41 .37(c)(ix) Evidence Appendix 

None. 

37 C.F.R. § 41 .37(c)(x) Related Proceedings Appendix 

None. 
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Conclusion 



Appealed claims 31 to 49 are submitted to be patentable. Reversal of the 
Examiner is, therefore, respectfully requested. 



Respectfully submitted, 



/Robert Charles Beam/ 
Robert Charles Beam, Esq. 
Reg. No. 28,182 
Attorney for Applicant 
(973) 724-341 1 

Mailing Address: 
U.S. ArmyARDEC 
Attn: AMSTA-AAR-GCL 
R. Beam / Building 3 
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